What

This PR generalizes the signature of internal event handlers from Consumer<WatchEvent> to BiConsumer<EventHandlingWatch, WatchEvent>. Thus, when internal event handlers are called, they also get access to the watch that dispatched the event.

This change affects only the internals of the library (currently only the JDK...Watch classes, but later also the macOS code). The end-user API still expects Consumer<WatchEvent> (or WatchEventListener).

Why

Imagine an overflow event happens, so the directory needs to be rescanned. Before this PR, the event handler of the watch could look something like this (simplified code, just to make the point):

class FooWatch implements EventHandlingWatch {

  ...

  @override
  public void handleEvent(WatchEvent event) {
    if (event.getKind() == WatchEvent.Kind.OVERFLOW) {
      var events = rescanDirectory(); // Returns a collection of rescanning events (CREATED or MODIFIED)
      for (var e : events) {
        // Recursively call this method for each of the rescanning events
        handleEvent(e);
      }
    }

    // Run the user-defined event handler
    this.eventHandler.accept(event);
  }
}

The point is that, to auto-handle overflow events, the auto-handler must access a watch to dispatch rescanning events (i.e., call the watch's handleEvent method). There are several alternatives to achieve this, including:

1. Define auto-handlers inside the watch class -- This is essentially what currently happens in JDKRecursiveDirectoryWatch
2. Define auto-handlers outside the watch class; pass a watch class reference when the auto-handler is constructed
3. Define auto-handlers outside the watch class; pass a watch class reference when the auto-handler is called

The problem with alternative 1 is that each auto-handler class should be usable with multiple watch classes (otherwise, we're potentially duplicating a lot of code). The problem with alternative 2 is that each auto-handler instance should be usable with multiple watch instances (otherwise, we're potentially duplicating a lot of handler objects that do essentially the same thing).

Thus, this PR implements alternative 3. It enables:

• Defining auto-handler code completely independent of the watch classes (as long as they implement the EventHandlingWatch interface, which has method handleEvent)
• Construct a single auto-handler that can be (re)used by multiple watches

(Usages of these features are demonstrated in the next PR.)